fix(persona): one predicate for what a context is, and colour that says which way a copy went - #192

Rebased onto main now that #191 has merged, so this is one commit and speaks attribute throughout.

Two things the live console was getting wrong on the persona pane.

A context was denied and drawn at the same time

The map answered "is this holder known here?" with three different tests:

1 + 10 ≠ 12, and the context that fell through the crack was drawn under a band captioned where you are known while the header denied it.

The state underneath is real, and it had no words anywhere on screen. persona/binding/list/1.0 enumerates the personas present in a context and carries bound separately, so unbinding a face leaves the persona behind: that context still knows an identifier of the holder's and can address it, while holding none of their attributes. Calling that known overstates what left; folding it in with they hold nothing about you hides an identifier the holder has out there.

standingOf / tallyContexts (identity-graph.ts) now give one predicate with four answers — known, identified, unreadable, absent — and the header, the band and the fold all read it. A test pins that the four sum to the total. The card keeps its place under its own heading:

An identifier only — glenn-vta · wears nothing
This context can address that identifier. It holds nothing else of yours.

Colour, in three channels that never overlap

Border = selection and reach. Stripe and chip dots = classification. Pills = status.

• Direction. reachOf has always run asymmetrically — down from an attribute to where copies of it went, up from a context to what it holds — and one accent hid the asymmetry it was computing. Down borrows --m-act-data from the contexts band it ends in; up keeps the accent; a face selection splits visibly across the dashed line, which is the model the pane exists to teach. Flow is computed in identity-graph.ts with the rest of the model — the component still only draws. The key appears with the first selection and not before.
• Family. Attribute cards group under their claim-type family (Who you are, How to reach you, Where you already appear, Your agent asks first, Not in the registry), with the hue repeated as a dot on every face's type chips, so a composition reads without opening it. attribute-family.ts classifies only roots the vendored registry declares — profile.* and employer land in Not in the registry, because inventing a "profile" family here would draw a grouping nobody has agreed to, in a colour that reads as though someone had checked.
• The palette rule holds. --m-fam-* are categorical, the same species as the act colours; --w-ok / --w-warn / --w-danger remain the only colours that mean anything. A test asserts no family's words claim the colour protects something: the stripe defends nothing, exactly as the mask beside it defends only a screen.
• Unlit "wear" edges went neutral — teal used to mean "a face is worn here" at rest and "this is the path you selected" when lit.

Checks

• 19 new tests. Extension 328 pass, core 548 pass.
• tsc -b clean across workspaces; npm run build clean, manager.js still a single chunk and dist/background.js unchanged.
• Reach direction, the four standings and their sum, the family rules and the no-overclaim rule are all pinned; the three new render tests mount the real pane.

Not in this PR

• CLAUDE.md's vocabulary paragraph still says the on-screen word is fact — docs(persona): the on-screen word for an attribute is "attribute", not "fact" #191 changed the code and the guard but not that paragraph.
• The same file says claim-sensitivity.ts has "deliberately no prefix walk". It has one now (trust-tasks#377, tightening-only), so the note reads backwards.